• Fixes TimedEvents.RunTimers executes callbacks while holding the timeout queue lock #5652

Summary

• Execute timeout callbacks outside the timeout-queue lock so callbacks can add or remove timers and IApplication.Invoke can enqueue work from other threads. Because Invoke is implemented as TimedEvents.Add (TimeSpan.Zero, …), every cross-thread Invoke, Post, and Send previously blocked for the full duration of every timer callback.
• Serialize callbacks with a reentrant runner gate. A competing RunTimers call returns, a later pass handles remaining due timers, and callback exceptions propagate directly and end the current pass.
• Assign each queued timeout occurrence an identity and execute only occurrences already due when a timer pass starts. This prevents an immediately repeating timeout from spinning or consuming every pass slot ahead of an already-due peer.
• Treat a reused Timeout reference as one cancellation token: Remove cancels all queued and active occurrences ordered before it without interrupting an executing callback. Removal generations and a StopAll epoch keep later additions unaffected without allocating per callback.
• Scan the whole queue by reference in Remove and GetTimeout. Both previously used SortedList.IndexOfValue, which returns only the first match, so removing a Timeout that had been queued more than once left the remaining occurrences scheduled and still firing.
• Cancel an in-flight repeating callback. Remove during execution was previously a silent no-op, and the callback rescheduled itself regardless.
• Return a synchronized snapshot from Timeouts, validate Add(Timeout) inputs at the call site, and report the collision-adjusted queue key through Added.
• Raise TimedEvents.Added after releasing the queue lock. A concurrent runner may execute a due timeout before its Added handler runs.
• Evaluate virtual Timeout.Span getters and injected time providers outside the queue lock. Repeating occurrences remain active during these reads and revalidate their removal generation and StopAll epoch before rescheduling. Empty timer passes return before reading the provider.
• Replace the orphaned <inheritdoc/> on CheckTimers, which is not declared on ITimedEvents and therefore inherited nothing.
• Cover direct IApplication.Invoke and MainLoopSyncContext.Post/Send paths introduced by Fixes #5636 - Scope MainLoopSyncContext to running sessions (await-before-RunAsync deadlock) #5641. Send enqueues without the timeout-queue lock but still waits synchronously for main-loop execution by design.
• Document the concurrency, cancellation, event-ordering, exception, and synchronous-dispatch contracts, including that an Added handler exception ends the timer pass while leaving the timeout scheduled.

SkillView consumer reproduction

SkillView 0.3 exposed the lock cycle in a real nested-modal workflow. A timeout-delivered UI callback opened the cleanup modal, then the removal worker tried to report its terminal progress through IApplication.Invoke. The captured stacks were:

UI:     CleanupScreen.Show → IApplication.Run → TimedEvents.RunTimersImpl
worker: RemoveService.BatchProgressAdapter.CompleteBatch → CallbackProgress.Report
        → CleanupScreen.InvokeIfActive → IApplication.Invoke → TimedEvents.AddTimeout → Monitor.Enter

The worker had completed two removal validations with refusals, but it could not enqueue the completion callback while the outer timer callback retained the queue lock. The modal therefore stayed on removing...; pressing Escape changed it to canceling removal..., but cancellation could not finish and the rest of the UI remained unavailable. CrossThread_Invoke_Executes_During_Nested_Run_Started_From_Timeout now covers this combined condition and verifies that the queued callback executes while the nested dialog is active.

Testing

• Required CI: all build, documentation, performance, integration, and unit-test jobs passed on macOS, Ubuntu, and Windows
• Targeted build: 0 errors and 3 pre-existing warnings — CS0419 in ViewBase/View.Drawing.cs and CS1574 ×2 in Views/DropDownList.cs. None are in files this PR touches, and the change introduces no new warnings.
• TimedEventsTests: 40 passed
• Nested-run tests: 6 passed
• Timeout tests: 38 passed
• Non-parallel tests: 72 passed, 2 skipped
• Integration tests: 343 passed, with the known local GitVersion assembly-version failure
• Full parallel run: 17,628 passed, 17 skipped, with 5 unrelated ANSI/color-output baseline failures

Verified behaviors

Beyond the assertions in the suite, these were confirmed with throwaway probes:

• A repeating TimeSpan.Zero timeout runs exactly once per pass. Before the pass bound, it re-ran indefinitely — measured at ~17.4M invocations in 3 seconds with RunTimers never returning, which starves drawing, input, and shutdown.
• A zero-span repeater no longer prevents an already-due peer from running in the same pass. Both zero-delay regression tests use lock-free stop signals so a broken pass bound fails cleanly instead of hanging during cleanup.
• A throwing callback leaves no residue: the active-state map, the occurrence-ID map, and the queue all return to empty.
• A throwing Added subscriber on the reschedule path leaves the active-state map empty and the queue and occurrence-ID map consistent; the timeout stays scheduled and later passes keep running it.
• Blocking Timeout.Span overrides and time-provider reads no longer block concurrent timeout removal or addition; cancellation during a repeat-interval read still prevents rescheduling.

Review notes

Draft pending final review. The normal local GitVersion step hung in GitVersion.MsBuild on one machine; the equivalent build with DisableGitVersionTask=true passed, as does a plain dotnet build. Solution builds emit only the pre-existing compiler warnings listed above plus sandbox-related NuGet audit-cache warnings (NU1900).

To pull down this PR locally:

git remote add copilot https://github.com/harder/Terminal.Gui.git
git fetch copilot fix/5652-timed-events-locking
git checkout copilot/fix/5652-timed-events-locking